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ABSTRACT 

,This paper discusses the use of Computer Supported 
Cooperative Work (CSCW) techniques for computer-aided learning (CAL) ; 
the work was started in the context of project Nestor, a joint effort 
of German universities about cooperative multimedia 

authoring/learning environments. There are four major categories of 
cooperation for CAL: author/author, author/ 1 earner , tutor/ learner , 
and 1 earner/ learner . In GROUPIE (Group Interaction Environment), a 
generic support system which was carried out in the Nestor project, a 
common model and taxonomy of cooperation was established; features 
include universal development support and a runtime support system. 
In his system, cooperation is viewed as an aggregate of two 
lower-level concepts, interaction and coordination* CoopEC 
(cooperating within the European Community learning domain), an 
example of CAL-speci f i c courseware, teaches about the EC and features 
a cooperative problem solving process; this software includes a 
questionnaire, a mul t i t ransi t i on between private and group learning, 
flexible coupling modes, and both online conferencing and 
asynchronous document exchange. A more liberal approach to commercial 
courseware is the authoring system, Nestor-ADP, which consists of 
cooperation-transparent tools, cooperation-aware tools, and the 
cooperation-aware lifecycle support environment, DIRECT. In DIRECT, 
the encompassing graphical user interface supports the cooperative 
construction of complex, hierarchically structured issue-position 
argument graphs. In general, two areas of cooperation support are 
distinguished: author/author cooperation, which involves multiple 
cooperation-aware tools and learner/side cooperation, which must be 
supported by generic development support for cooperative courseware* 
(AEF) 
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Abstraat This paper discusses the use of Computer Supported Cooperative Work (CSCW) 
techniques for computer-aided learning (CAL). The work described was started in the context 
of project Nestor, a large joint effort of german universities and Digital about cooperative multi- 
media authoring/learning environments (Muhlhauscr and Schaper 1992). We wiJ! motivate the 
specific importance and benefits of CSCW in the CAL domain (chapter 1). Chapter 2 concen- 
trates on a very generic support system,, called GROUPIE, which we developed, and shows how it 
was tailored to CAL; sample cooperative courseware will also be briefly discussed. Chapter 3 
covers the second important kind of CSCW support, pre-built cooperative tools, and illustrates 
their use in a framework for cooperating authors, called DIRECT. 



1 Motivation and Classification 

The importance of CSCW for the CAL field has been recognized early on, cf. (Wilton 1985; Ward 1991; Smith et al. 
1989). As to the authoring side, CAL research in the past years has shown that profound expertise in several disjunct 
areas is required in order to develop appealing and effeaive instruaional material: domain knowledge (about the area to 
be taught), instructional design knowUdge {^owi instruaional strategics, learner and knowledge modeling, courseware 
lifecycles), and media and interface design expertise, A single individual can hardly cover all these areas in detail. As a 
consequence, several people have to cooperate during die process of courseware development in order to obtain rea- 
sonable quality. Quite often, such experts work at physically disjuna places. Thus the need for authors to cooperate. 

On the learner side, the situation is even more urging: after decades of ITS research, it is recognized that computers 
can not entirely replace human tutors. As a consequence, learning environments should offer die possibility for the 
learner to get assistance by knowledgable people (the author, a tutor). Cooperation with authors emphasizes usually on 
Iterative Teedback loops' that help both the learner (in understanding the subjea or the courseware utilization) and the 
audior (in getting hints for improvements). Using more advanced 'liberal' approaches, the distinction between authors 
and learners even becomes blurred, e.g., if a group of authors tries to acquire knowledge about a domain. 

An even more important motivation for cooperation on the Jeamer side is deeply rooted in the modern educa- 
tional system. The pressure on pupils and students to reach high standards produces' rather isolated graduates, accus- 
tomed to working alone. Modern media and, not to die least, PCs have largely contributed to this Monc wolf 
syndrome*; CAL runs the risk of aggravaring diis negative trend. At the same rime, industry and economy move 
towards the global village^ hardly any reasonable task can be achieved by individuals any more, teamworking skills are 
strongly required. It is therfore crucial for the success of CAL that courseware addresses cooperation among learners. 
1 his g. J can only be achieved if teamwork aspects arc included in as much courseware material as possible. 

To summarize, four major categories of cooperadon can be identified for CAL: author-author, author-lcarncr, 
tutor-lcarncr, and Icarncr-lcaxner (note that an individual may play several of these roles in diflFerent contexts). 

Geneve authoring support: interesringly, all but the first one of these categories must be considered in the 
cour.<;cware ^tself. Since courseware is individually designed for each domain and purpose, pre-built cooperation tools 
for learners ar. not very helpful. Early attempts like the provision of electronic mail connections or even videoconfer- 
encing h?ve proven to be of limited use. Such approaches require the luers to talk about the courseware instead of using 
it cooperatively. E.g.. for a tutor to provide efficient help, he might need to 'look at' the learner screen, ^ask' the 
a)ur.^ware about the learner histor)-. and make remote input to the courseware. Efficient learner cooperation require* 
that the norion of different learners is 'known to the courseware and supported. To summarize, generic authoring sup- 
port for cooperative courseware is crucial in an authoring/learning environment (cf chapter 2). 

Cooperative authoring tools: the first categor)' above, author-author cooperation, is more suited for pre-built cooper- 
ative tools than the learner-related scenario.^;. Chapter 3 will concentrate on this issue in more detail. 
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2 Generic Authoring Support for Cooperative Software 



2.1 Domain-Independent Generic Approach 

We investigated many existing cooperative systems in diverse domains, drawing three major conclusions (Rudcbusch 
1993). 1: The field of CSCW is lacking a comprehensive and systematic taxonomy; the well-known time-spacc-cate- 
gorization (Johansen 1988) is useful but much too restricted. 2: Most existing cooperative applications represent dedi- 
cated implementations (wrt. application domain and interaction patterns). 3: All existing CSCW implementations 
were large programming efforts, again and again realizing similar cooperation functionalities from scratch. 

In the Groupie (Group Interaction Environment) development which was carried out in the Nestor projects we 
first established a common model and taxonomy of human-human cooperation in distributed systems. Based on this 
model, we realized a universal development and runtime support system for cooperative software. Last not least, we 
used Groupie to build example cooperative applications. In GROUPIE, the taxonomy and model oi cooperation in 
distributed systems is viewed as an aggregate of two lower- level concepts, namely interaction and coordination, 

A) Interactions this term denotes any user-initiated action in a CSCW context. It is the basic means of coopera- 
tion. Just as aaions in a single-user scenario arc performed upon objects (e.g. resizing a rectangle in a graphical editor), 
interactions are performed upon so-called team objects. This new concept extends the well-known object metaphor 
from single-user work to teamwork. (In the example, resizing the rectangle could be made visible to other group mem- 
bers.) Interactions can have a variety of characteristics, as depicted in fig. 1, "Interaction characteristics". 
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In the outset, an actions is defined as usual as an operation performed on a (basic or complex) object. The action 
description is then augmented to an intcraaion via the interaction context, comprising three components. 

The visthility component specifies the partners for whom the current interaction is visible (e.g. group members tak- 
ing part in the cooperative editing of a document). By setting the visibility to 1:0, a single-user action can be specified 
as a special case of an intcraaion. (In general, team objects provide a compatible extension of single-user work towards 
teamwork, as private work is always consistently supported as a special case of group work.) 

The synchronism component is again subdivided into three components. First, a maximum time delay between the 
initiation of an interaction and its visibility at a partner can be given. Second, the granularity describes the quantum of 
sub-actions to be transmitted to a parmer (e.g. when resizing a rectangle, each pixel movement, each interval of 10 
pixel movements, or only the completed operation can be transmitted). Third, the representation at a partner can be 
syntactical (exactly the same view), semantical (consistent data but different views, e.g. a pie chart and a bar chart for 
an integer array), or descriptive (only indicating that an operation has been performed, e.g. max has edited figure T). 
Synchronism can be described for each partner individually (e.g. reflecting a tightly cooperating group in a local net- 
work with loose connections to a geographically remote member). 

The modeof2x\ interaction ts explicit when a team object is deliberately sent to a partner (e.g. when sending a doc- 
ument via email). Interaction takes place implicitly when acting upon shared team objects (e.g. in a multi-user editor). 

B) Coordinations this concept is orthogonal to interaction (i.e. each ajordination characteristic can he combined 
with each interaction characteristic). We speak of basic coordination (or micro coordination) when low-level aspects 
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like authorization and concurrent access arc regulated. Complex coordination (or macro coordination) rixogniz*:., 
a.mpositc t«k.s and regulates work flows or conversation structures. In our model, a coordinating framework can be 
..p<:ahcd (,n the bcgmning independently) for teams and for task.,. In a second step, a team and a task description are 
ambincd into a coopcrauon description. This fosters reusability to a high extent. 

Coordination comprises team-, task-, and cooperation-specific aspects. A uam is described by team-roles and an 
interaction structure. Team roles abstract from specific users in the team context (e.g. leader, member, protoa.l- 
kccpcr). Interaction structures define interaction paths between team roles (fully democratic, stricdy hierarchic, etc) 

A task IS more complex to describe. Task roles abstract from specific users again, here however as related to the ta.,k 

• ■ Tx^ "^""^ ^""^ "^f' team object, authori?^- 

tion o\ different task roles and conflict resolution for concurrent access can be specified. Complex tasks can be decom- 
posed into sub-tasks recursively Constraints watch over sequences of sub-tasks, temporal and logical conditions. 

A cooprratton associates a team with a common task by mapping team-relevant and task-relevant roles. 

Coordmatton takes place on an intcraaion granularity, i.e. each interaction during task performance is checked 
against the coordinauon descriptions. Coordination can also influence task performance actively by guidine team 
members (e.g. suggesting a next sub-task to work on, based on the coordination desaiptions) 

Development support in the GROUPIE system comprises a library of team objects, fomial languages (for team, 
task, and cooperation desaiption) and cooperative tools and methods. Thus, CSCW functionality is implemented on 
an object granularity, as opposed to the common approach of tool granularity. Teams and tasks are not strialy pre- 
defined but can dynamically be adapted to changing needs. A cooperative method for developing CSCW systems in 
tcajns has been implemented and can be reused or further refined (bootstrap approach). 

The runtime system: GROUPIE distribution support provides a high-level object-oriented interface based on 
(home-brewn) Distributed Smalltalk. Distribution management dcdd^ Jibout migration, replication, and consistency. 
Cooperative applications are embraced by (guiding and checking) coordirmtion support, interaction handling, interpret 
and reali^s an interaction context. It is possible to integrate existing single-user applications in a cooperation-transpar- 
ent way (for the term cooperation-transparent, cf. chapter 3). 

2.2 CAI^Specific Extensions to GroupIE and Sample Courseware 

According to our concept of generic support for cooperative software as introduced above, adaptation to specific appli- 
«tion domains such as CAL is technically simple. Existing base classes need to be adequately refined. Much more dif- 
ficult IS the quesuon of what are adequate team objects and strategies for cooperative courseware'" 

Cooperat,veprobUm solving can, in a first approach, be supported by simply providing an information space to the 
learners that is freely accessible. Information about the learning domain can be retrieved both cooperatively and indi- 
vidually if all mformaaon objects are realized as team objects (e.g. documents, video sequences). Student evaluation 
requires dedicated earning objects (e.g. questionnaire, multiple choice documents for cooperative completion); tutors 
(with speofic privileges may be involved. Cooperative strategies are even more interesting: weU-known learning strate- 
gies for individuals (drill&practia, tutorial, exploratory learning, etc.) must be complemented by cooperative ones 
which. e.g., take into account different roles of learners. E.g., procedural knowledge of legislation in the European 
Commumry may be taught based on various roles of delegates in the Commission; a cooperative strategy for informa- 
aon acquisition is described in ch. 3; a motivational approach might use the paradigm of 'multi-user dungeons', etc 

COOptL (cooperating within the European Community learning domain) is as sample courseware for validation of 
our concepts^ coopEC teaches about d.e EC and features a cooperative problem solving process and working on various 
documents^ Four basic team objects specific to CAL have been developed in the first version: a questionn^re. a multi- 
ple choice document, a map of Europe with hot spots, and a f«:e-form text/graphics document. It supports dynamic 
transition between private and group learning, flexible coupling modes, and both on-line conferencing and asynchro- 
nous document exchange. Once enrolled.students can also be sent documents while logged off. 

Fig^ 2 shows die main window of coopEC. The sub-window at the top is used for cooperation control. The very 
detailed set of possible interaction characteristics as introduced in chapter 2.1 has been customized into a few user- 
selectable combinations, each acassible via one respeaive button, that seemed most appropriate for this specific set- 

The user can, at any time, choose 'private' work or cooperate with his partners. To cooperate, he can 'share' docu- 
ments (with the whole group or a sub-group) or 'send' a document to any number of panne rs. The closeness of a 
cooperation can be determined by selecting one of three 'coupling' buttons. With 'tight' coupling in share mode, all 
partners have the same view on the shared document. Any operation, like typing a single chaLter, is visible for each 
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of the partners. Full telepointing is supported, as the movement of each partners* mouse pointer is overlaid onto the 
shared document. In send mode, tight coupling results in a mail window automatically being brought on top of all 
other windows for each receiver, ^Medium* coupling in share mode transmits only completed interactions. E.g. when 
filling out the questionnaire, only complete answers are transmitted to the partners. *Loosc* coupling, whether in share 
or send mode, just prints a textual information about the operation performed in the message area at the very bottom 
of the main window. The sub-window below cooperation control provides mcta information about users and modes. 
coopEC supports two roles: tutor and learner (indicated in brackets). Users listed as inactive have never accessed the 
course. A unique color is mapped to each user. This is extremely helpflil when sharing a document (to distinguish 
multi-user input and telepointers). Green is reserved for the tutor, making him easy to identify. 

Four buttons questionnaire*, multiple choice*, *curo map*, and note* are provided to select a document to work on 
(details skipped for the sake of brevity). As an example scenario, a learner could decide to start a cooperative question- 
naire by answering the questions he already knows. He may then invite some of the enrolled students to share this 
pardy completed question nairc.The sub-group can then cooperate by inserting or correcting answers (the color of each 
answer text dynamically changes to the unique color of the current editor). Telepointers can be used to indicate issues 
currently in discussion. The learners may decide to involve the tutor and finally submit the questionnaire. 



coopEOI tfriftwood - nUph j - | j| 




FIGURE 2. Top-level user interface for tOOpEC 
3 Cooperative Authoring Tools and Lifecycle 

Commercial courseware development has in the past been based on rather prescriptive lifecycles. New management 
theories and cooperation trends suggest more liberal approaches, as docs the academic working style. We will concen- 
trate on such a more liberal approach in the remainder (more prescriptive lifecycles can easily be supported). The 
resulting authoring system Nestor-ADP is comprised of cooperation-transparent tools, cooperation-aware tools, and 
the cooperation-aware lifecylce support environment DIREGl 

Cooperation transparent toolst this term refers to tools which have been built with a single user in mind. The 
idea is to extend them transparently for use from multiple user interfaces, possibly in a distributed system (the advan- 
tage that existing tools can be augmented is paid with limited cooperation funaionality). 

Nestor tool "shX*": In the context of our project Nestor, generic cooperation support for cooperation-transparent 
software has been developed, called "shX". shX allows prebuilt Xwindow™ -based application software to be used 
from multiple workstations (even without recompilation or rebinding). Ail output from the application is replicated to 
all participating workstations. shX offers different so-called floor passing schemes, ranging from 'prescriptive token- 
based* (only one user has control at a time) to ^anarchy mode* (uncontrolled multiple input). New schemes may be 
added, such a.- role-spccific ones (e.g., *tutor-lcarner*, where die tutor always has superior input rights). 

IDE'shX: since Nestor tries to support the entire courseware lifecycle. wc built a specific tool for the early 
courseware design phase, allied 'instructional design editor'. This tool allows to arrange instructional goals and objec- 
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dves graphicaliy into a semantic n^.v/ork, relating these instructional issues to domain knowledge. IDE understands' 
several instructional strategics. IDE has been extended by shX in order to allow cooperative courseware design. 

CSE-shX: IDE-based designs can be 'compiled* with one of the instructional strategies implemented in IDE, gener- 
ating template course structures for the 'course struaure editor* CSE. CSE is based on a high-level graphical noution 
for the flow of control and aaions in the courseware, called 'instructional transactions. The template generated (by 
IDE) for CSE provides the courseware skeleton which has to be complemented by concrete screen and media designs 
and by fine-tunmg for the instructional transactions. A cooperative shX-based extension of CSE has been built. In the 
long run. we plan to implement cooperation-aware successor tools to IDE and CSE based on GROUPIE. 

Cooperation-aware toolst as mentioned above, cooperation-transparent applications ate very restricted. E.g, they 
can hardly be used if teams work together at different times. Since the courseware lifecycle is a long-living activity, such 
asynchronous cooperation is however crucial. Therefore, we had to build several cooperation-aware tools plus a «)op- 
eraaon-aware lifecycle fi-amcwork encompassing the (cooperation-transparent and -aware) tools. In addition, integra- 
tion of audio and video conferencing support was found to be an absolute requirement for efficient cooperation of 
physically distributed authoring teams. 

Groupie itself is, for the moment, our most important cooperation-aware environment. In ..ddition, the follow- 
mg cooperation-aware project management tools were buUc a meeting coordination tool which inrerworks with pri- 
vate calendar tools and with the other tools listed here; a group mail system (which uses the user'j standard mail for 
sending/reccivrng mail); individual calendar tools; a time / task planner based on critical path ne-.works CPN. Apart 
from that, tools for audio and video conferencing have been implemented, featuring dynamic conference manage- 
ment. The audio conferencing is based on our low-cost SCSI™-based hardware audio exrension for workstations. 
The video conferenang support uses vendor-supplied frame grabbing boards and a home-brewn software video codec, 
called SMP (Neidecker-Lutz and Ulicheny 1993). 

Cooperation-aware Ufecyde support: at a first glance, one may decide to base a cooperative framework for 
courseware lifecycle integration on traditional courseware development processes. However, it was already argued in 
chapter 2 that modern views of cooperative work rend to seek new, more liberal management and organization 
approaches than the model of subsequent "phases** (like 'define*, 'design*, 'develop*, 'deliver*,...). In fact, if courseware 
development should lead to new inreresnng solutions, the outcome and goals are not very clear at the outsef 
courseware development becomes an 'ill-structured problem*. An excellent approach to coping with such ill-structured 
prob ems has been presenred in (Potts 1989). called 'issue-based design*. In our project, we adapred this concept to the 
problem spaa of courseware development and implemented a cooperative framework accordingly. The framework 
was called UlKtU (distributed research and engineering for cooperating CAL teams). 

The courseware-adapted issue-based design approach shall be briefly described here. According to this approach, 
the problems associared with developing a specific courseware are struaured into 'issues* (each issue can be hierarchi- 
cally separated mto sub-issues). For each issue (or sub-issue), different approaches may be identified over time (these 
approaches are called 'positions* according to the original method), and arguments supporting or objecting to an 
approach may be collected in the cooperating group of authors. In OIREQ. the encompassing graphical user inrerfaoe 
supports the cooperative construaion of complex, hierarchically structured issue-position-argument graphs. A partic- 
ular value of the system srems f^om the provision of authoring-spedfic issue-position-argument remplatcs which are 
predenned for reuse. 

According to the method, the authoring team has to opt for one of the alternative approaches to an issue. At this 
point, a number of po«ible socalled 'steps* are offered to the authors which they can choose f^om in order to resolve 
the issue (an example for a standard step is the development of a courseware module). It is (mainly) here that the 
above-cired tools are hooked* into the encompassing framework: if a specific step is chosen, a kind of 'workflow sup- 
port sysrem is starred which manages the coordinated use of the above-mentioned courseware design/development 
tools, project management tools and audio/video conferencing tools. Our experience has shown that this integral 
approach has a lot of advantages over the uncoordinated use of individual cooperative tools. As an example, if a srep 
starts with the definition of a task force (e.g., assigned for the development of a specific courseware module), then sub- 
sequent tools can br automatically provided with the names and network addresses of the relevant group participants. 

The screenshot in fig. 3 shows the screen of a DIREQ user, a partial display of an issue-position-argument graph 
lupper right) and some cooperaave tools which arc actually in use by the author (e.g., IDE-shX at the lower left). 

4 Conclusions 

We have shown that two basic area., of cooperation support have to be distinguished, author-author cooperation and 
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Icarncr-sidc cooperation. Leamcr-sidc cooperation must be supported by generic development support for cooperative 
courseware rather than by tools. Author-author cooperation involves multiple cooperation-aware (and maybe coopera- 
tion-transparent) tools and can be best accomplished with the help of an encompassing framework. The latter was 
described based on a liberal courseware lifecycle. Stable versions of GROUPIE, (OOpEC, cooperative authoring tools and 
DIRECT as described arc actually running on our premises and at several external sites. 




FIGURE 3. Sample Screenshot of the DIREQ Co ursewaxe Lifecycle Framework 
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